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Not All RFCs are Standards 
Status of this Memo 
This memo provides information for the Internet community. This memo 
does not specify an Internet standard of any kind. Distribution of 
this memo is unlimited. 


Abstract 


This document discusses the relationship of the Request for Comments 
(RFCs) notes to Internet Standards. 


Not All RFCs Are Standards 


The "Request for Comments" (RFC) document series is the official 
publication channel for Internet standards documents and other 
publications of the IESG, IAB, and Internet community. From time to 
time, and about every six months in the last few years, someone 
questions the rationality of publishing both Internet standards and 


informational documents as RFCs. The argument is generally that this 
introduces some confusion between "real standards" and "mere 
publications". 


It is a regrettably well spread misconception that publication as an 
RFC provides some level of recognition. It does not, or at least not 
any more than the publication in a regular journal. In fact, each 
RFC has a status, relative to its relation with the Internet 
standardization process: Informational, Experimental, or Standards 
Track (Proposed Standard, Draft Standard, Internet Standard), or 
Historic. This status is reproduced on the first page of the RFC 
itself, and is also documented in the periodic "Internet Official 
Protocols Standards" RFC (STD 1). But this status is sometimes 
omitted from quotes and references, which may feed the confusion. 


There are two important sources of information on the status of the 
Internet standards: they are summarized periodically in an RFC 
entitled "Internet Official Protocol Standards" and they are 
documented in the "STD" subseries. When a specification has been 
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adopted as an Internet Standard, it is given the additional label 
"STD xxxx", but it keeps its RFC number and its place in the RFC 
series. 


It is important to note that the relationship of STD numbers to RFC 
numbers is not one to one. STD numbers identify protocols, RFC 
numbers identify documents. Sometimes more than one document is used 
to specify a Standard protocol. 


In order to further increase the publicity of the standardization 
status, the IAB proposes the following actions: 


Use the STD number, rather than just the RFC numbers, in the cross 
references between standard tracks documents, 


Utilize the "web" hypertext technology to publicize the state of 
the standardization process. 


More precisely, we propose to add to the current RFC repository an 
"html" version of the "STD-1" document, i.e., the list of Internet 
standards. We are considering the extension of this document to also 
describes actions in progress, i.e., standards track work at the 
"proposed" or "draft" stage. 


A Single Archive 


The IAB believes that the community benefitted significantly from 
having a single archival document series. Documents are easy to find 
and to retrieve, and file servers are easy to organize. This has 
been very important over the long term. Experience of the past shows 
that subseries, or series of limited scope, tend to vanish from the 
network. And, there is no evidence that alternate document schemes 
would result in less confusion. 


Moreover, we believe that the presence of additional documents does 
not actually hurt the standardization process. The solution which we 
propose is to better publicize the "standard" status of certain 
documents, which is made relatively easy by the advent of networked 
hypertext technologies. 


Rather Document Than Ignore 


The RFC series includes some documents which are informational by 
nature and other documents which describe experiences. A problem of 
perception occurs when such a document "looks like" an official 
protocol specification. Misguided vendors may claim conformance to 
it, and misguided clients may actually believe that they are buying 
an Internet standard. 
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The IAB believes that the proper help to misguided vendors and 
clients is to provide them guidance. There is actually very little 
evidence of vendors purposely attempting to present informational or 
experimental RFCs as "Internet standards". If such attempts 
occurred, proper response would indeed be required. 


The IAB believes that the community is best served by openly 
developed specifications. The Internet standardization process 
provides guarantees of openness and thorough review, and the normal 
way to develop the specification of an Internet protocol is indeed 
through the IETF. 


The community is also well served by having access to specifications 
of which have been developed outside the IETF standards process, 
either because the protocols are experimental in nature, were 
developed privately, or failed to achieve the acquire the degree of 
consensus required for elevation to the standards track. 


The IAB believes that publication is better than ignorance. Ifa 
particular specification ends up being used in products that are 
deployed over the Internet, we are better off if the specification is 
easy to retrieve as an RFC than if it is hidden in some private 
repository. 
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Security Considerations 
Security issues are not discussed in this memo. 
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